Create aip for Aptos Intent Framework#511
Create aip for Aptos Intent Framework#511runtian-zhou wants to merge 5 commits intoaptos-foundation:mainfrom
Conversation
aips/aip-x.md
Outdated
There was a problem hiding this comment.
Does dispensable_resource sounds better here?
aips/aip-x.md
Outdated
There was a problem hiding this comment.
Are you intending for the argument to be a proof (either zk-proof or storage proof) that can be verified on-chain?
In theory, we could represent the argument as a function f(state, intent) -> bool, where solvers submit proofs for on-chain verification.
There was a problem hiding this comment.
In the current design, there's no proof involved: user specifies the post condition the transaction will need to meet, and aptos framework will assert this transaction can only be committed if post condition has been met. Argument is just some auxillary data to help the framework determine whether the transaction can be committed. It would be easier if you look at the move code directly.
|
|
||
| With those types being generic, we can implement different trading intents easily: | ||
| - If `Target` is instantiated with `FungibleAsset`, it means we are trading a Move value for a specific fungible asset. | ||
| - If `Target` is instantiated with `LinearTransferRef`, it means we are trading a Move value for an Object. |
There was a problem hiding this comment.
Should we also include NonFungibleAsset as a type? Some DeFi protocols mint NFTs for specific staking or deposit operations, right?
There was a problem hiding this comment.
Here are just examples. You can put arbitrary type here.
igor-aptos
left a comment
igor-aptos
left a comment
There was a problem hiding this comment.
You should add a note about this not being published at 0x1.
you can look at https://github.com/aptos-foundation/AIPs/blob/main/aips/aip-72.md#risks-and-drawbacks for what they wrote there, but it could probably be explained a bit more (and the reasons for going that way)
aips/aip-x.md
Outdated
There was a problem hiding this comment.
this is not necessarily for trading, but for creating offers. (i.e. offer can be more general than a trade)
For example, you could have an offer for a bet.
aips/aip-x.md
Outdated
There was a problem hiding this comment.
in the framework => in this AIP
aips/aip-x.md
Outdated
aips/aip-x.md
Outdated
There was a problem hiding this comment.
Framework code for creating and validating intents.
=>
Library code for creating and validating intents.
| - If `Target` is instantiated with `LinearTransferRef`, it means we are trading a Move value for an Object. | ||
| - If `Source` is instantiated with `TransferRef`, it means we are giving out ownership to an Object given certain condition. | ||
| - If `Source` is instantiated with `FungibleAsset`, it means we are giving out a certain fungible asset given certain condition. | ||
| - This doesn't quite work because `FungibleAsset` is not storable. The real implementation would look like giving out ownership of a `FungibleStore` |
There was a problem hiding this comment.
could this be hidden in the intent? i.e. it stores FungibleStore, but returns extracted FungibleAsset to the caller?
There was a problem hiding this comment.
Yes it is currently hidden for implementation.
aips/aip-x.md
Outdated
There was a problem hiding this comment.
this sentence probably goes to future work
| } | ||
| ``` | ||
| Here we are defining an example of intent where the unlock condition is receiving a certain amount of a given fungible asset type. `Argument` type is instantiated to `FungibleAssetLimitOrder` and `Witness` type is instantated to `FungibleAssetRecipientWitness` in this example. In the arugment, we specify the amount and the type of FA we would like to receive. The check will then be implemented by first checking if the passed in `FungibleAsset` meets the requirement set in the `FungibleAssetLimitOrder` and deposit the FA to the issuer's primary fungible storage if the conditions are met. Once the checks are completed, we will provide the witness `FungibleAssetRecipientWitness` to complete this intent session. | ||
|
|
There was a problem hiding this comment.
this needs an example of snippet of code of what the issuer and settler would need to do , for the above fungible_asset_intent_hooks.
aips/aip-x.md
Outdated
There was a problem hiding this comment.
it's not aptos_framework , but a different adress
aips/aip-x.md
Outdated
There was a problem hiding this comment.
I would rephrase this:
As the system is first-come first-serve, the intent claiming transaction can be front-runned by whoever sees it - mempool operator, validator operator, etc. Since anyone is able to sign transaction to claim intent solution, anyone can take the intent solving transaction submitted by the solver and sign the same transaction with its own address to be able to claim the lucrative ones. If main value comes from finding the route, and not being willing to settle, privacy of submitted transactions will become imporatnt. Intent Solver might want to run a validator node or partner with validator operator. Additionally in the future, support for "secret transactions" , that are revealed only at the time of execution might be added.
aips/aip-x.md
Outdated
|
Update the PR with @igor-aptos's comments |
3 participants
No description provided.